Which conventions should we follow in GMT project? There are Eclipse conventions at http://dev.eclipse.org/conventions.html . Should we follow those blindly?

In FUUT There is a target to run checkstyle with Sun conventions(Eclipse ones are based on them). We can use it to make sure our new code is good enough. Similar way could be applied in other GMT project components.

-- MarkKofman - 03 Jul 2004

FUUT: What about getting rid of warning list in the Eclipse's problems view? This issue could also be mentioned on the list of possible refactoring issues, but i believe first of all we should agree on what warnings we shall fix. Thus, this is also a coding convention issue ;)

-- AntonLitvinenko - 04 Jul 2004

FUUT: I have always used Eclipse with ignore warnings about unused imports. Now, with Eclipse 3, I found that there are >150 of them, so I am fixing them all. It makes the dependencies that we have more clear. I think that in the generated code it is more difficult to avoid unused imports.

-- GhicaVanEmdeBoas - 05Jul 2004

1. To be able store and load your resource as XMI you have to set-up Resource Type property to "XMI". By default resource type is not specified

-- MarkKofman - 26 Sep 2004

Since it is really difficult for a newbie to understand ideas behind the configuration of FUUT, i believe we need a document describing the purpose of each configuration file.

(Ghica) Here goes... There are three kinds of configurations:

1. start-up - Needed is a list of plugins to load, this list is supplied in a .ini file, and a .properties file.
   
2. code-generation - Needed is a list of templates to use for code generation. If you use the Fuut-je built-in template language, a cglist is needed, if you use Velocity templates, a vlist is needed. Each time the code generation action is invoked, you are given the possibility to choose a list, and the list is read. This means that you can create lists, or change them without stopping/starting Fuut-je. Very handy when developing templates.
   
3. batch-processing - Here a list of operations to be performed must be provided in an .ftbatch file.
   

-- GhicaVanEmdeBoas - 06 Jul 2004

Extensions of configuration files stand for:
cglist - code generation list
vlist - velocity list

While surfing through the FUUT documentation, i have found descritpions for some configuration files.
(Ghica - I am reorganizing this list according to purpose)
processing of a fuut model

conf/fuut2s.ini - List of FUUT plugins used for ... the basic Fuut-je configuration
conf/FtSuperTab.ini - List of FUUT plugins used for ... This list is an extension of the previous list and can be loaded multpiple times, since you can add new tab-panels, each with its own model to your Fuut-je workspace.
conf/fuutbatch.ini - List of FUUT plugins used during the batch processing of fuut models. Note that this is an example only. The actual list needed depends on the list of actions you want to execute, as provided by an .ftbatch file.

conf/FtSwingSet.cglist - A template set used to generate Swing components of generated application (correct?)
Not exactly. This is the basic set of templates needed to generate a full application with a Swing GUI from a Fuut-je model. This set is also used for the generated parts od Fuut-je itself.
conf/EMFStructure.cglist - A template set used to generate EMF structure of a model (correct?)
Almost. This is a set of templates that you can use to generate annotated Java. This Java you can use to import into EMF and EMF will create an EMF model out of it. This is the easiest way to convert a Fuut-je model into an EMF model.
conf/FtDocOnly.cglist - A template set used to generate FUUT documentation (correct? yes Javadoc? no, it is much more compact than Javadoc )

conf/Velo.cglist - A template set used to generate Velocity templates (correct?) -- this should be removed from CVS. It was a failed attempt to generate Velocity templates from Fuut-je templates. Not worth the trouble. (Ghica)

conf/php.vlist - ... this is a set of Velocity templates to generate PHP code and MySQL^? DDL from a Fuut-je model. It actually works great, and it is very much work in progress. (Ghica)
conf/FtvList.vlist - ... should be removed

conf/exampleBatch.ftbatch - An example file containing the sequence of actions to be taking during a particular batch procedure. Fuut-je batch processing is very handy to generate code in a build procedure. (Ghica)

resources/exampleBatch.properties - An example file containing the list of configuration properties used during the batch processing of a fuut model (Exactly what properties are defined here?)
resources/Ft.properties - List of configuration properties used for initialization of a swing-based FUUT frontend (correct? Exactly what properties are defined here?)
(Ghica) At start-up of Fuut-je you can specify a properties file as parameter (default: ft.properties). If you open up one of the files, the parameters defined in it are pretty obvious I think.
One execption: "InitialMessage = FtBatch^? conf/examplebatch.ftbatch" in the exampleBatch.properties indicates the first action to be taken after Fuut-je is started. In this case the FtBatch^? action, that takes the .ftbatch file as parameter (see the description about batch processing on the gmt site).

-- AntonLitvinenko - 04 Jul 2004

My suggestion for refactoring the startup configuration processing would be to combine the information in the .ini, .properties and .ftbatch files into one XML file.

Make a model using Fuut-je that can handle this information and generate code for it (see the Fuut-je tutorial). The generated code is capable of reading and writing XML in the desired format, it also has a Swing GUI that you can use to create/edit the XML files. You just have to write a little wrapper to interface this with FuutTool, or whichever module you choose to process the configuration information.

-- GhicaVanEmdeBoas - 06 Jul 2004

Before joining this discussion take a look at FuutConfiguration topic.

Do You think, it is better to separate batch processing configuration and GUI application configuration into separate parts of configuration? I believe it would be more convinient to have one configuration file (as You pointed out on the wiki) and some property of this would tell if FUUT-je to be ran as a GUI app or in batch mode. I think it is possible to create such structure that will represent/encapsulate equally well properties of both configurations. -- AntonLitvinenko - 06 Jul 2004

I think it is better, as I said in the wiki, to combine batch and GUI processing. Actually, Fuutje is not aware at all whether it is running batch or GUI. It depends on the plugins you are loading. You can even do batch in the GUI. It is like a movie you are showing then. -- GhicaVanEmdeBoas - 07 Jul 2004

Combining GUI FUUTje and headless FUUTje (running in batch mode) doesn't mean we should not separate configuration for those! I think final result we would like to achieve is that by configuring build script we can create distribution of headless FUUT or GUI versioned FUUT. It would be good not to leave too much configuration for a user. -- MarkKofman - 07 Jul 2004

It depends. It is not clear to me when you want to run the build. If it is done by us and we provide 2 different downloadable versions, I strongly disagree. The idea of various ways to run Fuut-je is to determine at start-up of Fuut-je what to include anf what not. Still, the user has more classes, not used at that moment in the jar on his local disk. -- GhicaVanEmdeBoas - 12 Jul 2004

One file vs many configuration files.  Sure one file is better, however I don't think it is reasonable sometimes. E.g. we will need to maintain 2 similar configuration files both for GUI FUUTje and for headless. It will make sence to break up the file into units logicaly and to reuse them. -- MarkKofman - 07 Jul 2004

I have already tried Jfig, XmlDigester^? and Castor tools for managing the XML configuration of projects. I think, it is a good idea to use FUUT-je facilities to manage its configuration, since if i am not mistaken this will let us to have configuration in a object-oriented style (like castor with its mapping files and marshalling/unmarshalling functionality). On the other hand Jfig is very simple and is very similar to java "properties configuration" in style. XmlDigester^? is capable of processing configuration in both object-oriented and properties style and it is quite easy to parse XMLs with it. But neither of these libraries have a tool for editing the configuration. So,in my opinion, it would be cool to generate such GUI tool by FUUT-je. -- AntonLitvinenko - 06 Jul 2004

You will find that Fuut-je is the easiest to use of all these tools, once you understand how a model maps onto the XML. Just do the tutorial, and look at the XML that is saved if you run the generated application and enter some data in it. -- GhicaVanEmdeBoas - 07 Jul 2004

Ghica, I guess you are a bit biased ;) Some points which in my opinion should influence our decision:

• Using FUUTje for configuration would be "politicaly correct" :). It is ideal case to show benefits of model driven approach or generative approach.
• Using a tool like Jfig can add additional features specific to managing configuration files and not only XML parsing
• By using tool meant specially for convinient XML parsing we could gain some good ideas and probably later implement them in the FUUTje

-- MarkKofman - 07 Jul 2004

Of course I am biased :-). Not unfounded though. I have encountered lots of different kinds of XML files in quite a few projects. Each time I have adapted Fuut-je to allow to handle parsing and modeling the XML in the easiest way possible. I did not try Jfig and I have no opportunity to do so now. How would we use it for Fuut-je? Let's have a more specific problem stement. What would you like to have in the configuration and how would you like to influence the build-running of Fuut-je with it, in addition to what is there now? -- GhicaVanEmdeBoas - 12 Jul 2004

I(Ghica) would like to make some remarks about splitting fuut into various jars, considering dependency management. Maybe we can talk about it tonight.

A candidate to put into a separate jar is the org.eclipse.gmt.fuut.common package. This is exactly the code that needs to be included in the classpath for all generated applications (including fuut itself).

What is exactly the functionality there? Is it possible to generate code which doesn't use this common package -- MarkKofman

(Ghica) The functionality of the common package is used by the current code generation templates. For example, it contains some Swing classes and the generic XML parser. If you write your own templates, you may avoid using the common package. It is a difficult question how much code you should provide with generated code. My first version of Fuutje had a whole framework from which the generated code inherited. The disadvantage is, that it is much more difficult to make changes to the code generation and to keep versions separate. The next version had no common code at all. It turned out that this resulted in a lot of duplication, and if you wanted to change something in code that is actually commmon, you have to re-generate all applications. So the common package contains what has proven to be actually common.

Similar for the org.eclipse.gmt.fuut.generator package. You will need it in addition to common if you are using code generation in your generated application.

Isn't it too specific case to deal with that? I guess the probability that you want to use fuut generator in you generated application is quite low. -- MarkKofman

(Ghica) At contrary. A common scenario for a model-driven application would be to first develop a (meta)model that constitutes your DSL. You can then generate an application from this (meta)model. For example the component model that Jorn made. Your action application would be modeled using the DSL and the final application is generated from the generated DSL application. In Fuutje you can use now either it's intrinsic templates that are suitable for Fuutjes own tool model or something close to it. For generated applications it is better to use VElocity templates to further generate code. Another common application for using generation in a (generated) application is for example to renerate reports or html. Velocity was specifically designed as an alternative to XSLT (XSLT is just another, rather difficult template language).

Another thing to think about is, whether we should split the packages differently. For example, if you would not want to generate code using Velocity, The easiest thing to do would be to remove org.eclipse.gmt.fuut.action.FtGenVelocity from the list in the .ini file. As a result, you would not see it, but the code is still there. Since the space it takes is peanuts it is not problem. From a dependency management point of view it would maybe be better to move FtGenVelocity^? to the org.eclipse.gmt.fuut.velocity package.

Rearranging packages differently sound good. But in this case we should proper design before. Doing it in refactorign style would take a lot of time -- MarkKofman

Eclipse has some good facilities for rearranging modules and packages. Almost everything is automatic. Of course you do not change functionality this way, but it can be very effective to get the dependencies between packages right.

We should be very careful to not create too many jars. In my previous job the final project had a classpath of some 50 items, and I went totally nuts from it, therefore I repackaged fuutje again into one jar instead of the original 3. It is nice to re-use open or other source from many places in a project, managing the classpath can become a real nightmare and a source of very difficult to spot bugs.

Are you worried about FUUTje own classpath or FUUTje generated applications classpath? If first, then one idea is using Maven? If second, I agree. I would say more: why should generated application be dependent on FUUT jars at all? Only dependency should be generation time, when you use FUUTje. -- MarkKofman

(Ghica) I am talking about the classpath for generated applications and the enveroment where they run in. -- GhicaVanEmdeBoas

-- MarkKofman - 28 Jun 2004

This is the list of refactoring ideas for FUUTje tool. Take any and implement it ;)

• Priority 1 - Combine different plug-in loaders
• Priority 1 - Improve FUUTje configuration(resource handling, plugin configuration, other configuration)
• Priority 1 - Refactor package structure of FUUTje. See also FuutDependencies discussion.
• Priority 2 - Think of new CVS modelue structure for GMT and FUUTje
• Priority 2 - Use Log4J for logging
• Priority 3 - Should we give FUUTje model files specific extension e.g *.fuut

-- MarkKofman - 03 Jul 2004

Models can be expressed in text, XMI etc. The most convenient form to visualize a model is trough a diagram. The most commonly used diagram notation is UML. A simple UML diagram consists of rectangles and lines between rectangles. The rectangles represent classes and the lines represent relationships between classes.

A class in a model should not be confused with a class that is implemented in a programming language such as Java. In business models there will usually be fewer model classes than programmed classes.

Model Diagramming in Fuut-je

The notation that Fuut-je uses for its diagramming is simplified UML, the rectangles represent classes or interfaces and the lines are 1-1 or 1-* relationships. Classes have attributes and methods, relations can have names, roles, multiplicity etc. A significant feature of Fuut-je is, that for each of the tool-model concepts: Classes, Attributes, Methods, Relations, the tool user can define new properties. These properties become part of the tool model and can be used/accessed to steer code generation.

The Fuut-je diagramming part was originally implemented in AWT, and later adapted to Swing. A diagrammer implemented using JHotdraw has been available, but was unfortunately proprietary. With the advent of Eclipse and SWT, and the inclusion of Fuut-je into GMT, the question arises whether Fuut-je should continue to provide its own diagrammer and if yes, whether this diagrammer should use SWT.

-- GhicaVanEmdeBoas - 29 Jul 2004

FUUTje Documentation

1. FuutBuild^? (Building FUUT tool)

FUUTje Tool Open Discussions

1. FuutDependencies (discussion of FUUTje tool internal and external dependencies)
2. FuutRefactoring (Ideas on refactoring of FUUTje)
3. FuutConfiguration (Q&A of FUUTje configuration) -- AntonLitvinenko - 04 Jul 2004
4. FuutConfigurationImprovement - Ideas on configuration improvement -- MarkKofman - 07 Jul 2004

This is intendet to be a collection of questions and answers regarding GMT architecture. It also is meant to store old discussion and to make GMT more clear to newcomers. As soon as this page is mature it can be a source for GMT FAQ

ARCHITECTURE DOCUMENT

Q: I think it would be of great value if you would start Architecture description with some introduciton. For example what do you mean by "GMT" or by "GMT tool set", "GMT Platform"? Purpose, Scope, Audience and Glossary would be simple to add, however would add great value! I would actualy create separate Glossary document, because terminology in GMT is quite important to understand.

A: A short Purpose, Scope, Audience is still missing. We should make a start. But there is no need for overlap with the glossary started on http://www.mdsd.info.

---

Q: What does "gcore" name stands for? GMT core? Isn't gmtcore a better name then?

A: Just sticking with the eclipse.emf naming style (emf.ecore & gmt.gcore).

---

Q: Are there any prerequisites to understand the document? I am still having hard time to understand architecture contents.

A: It's not complete yet. It's a living document that needs to evolve and grow over time. But it's not intended as an exhaustive design document! It's intention is to convey the big picture so that GMT developers can get started and know where to look for more detail.

---

Q: Why would GMT architecture contain "spectoolgenerator". Isn't it one of the pluggable MDA tool components? I am not getting point of its importance! I would concentrate first on building touchable core of GMT architecture and then take tool components one by one and try to integrate them.

A: Correct, it's the one [important] MDA tool component that's part of GMT. (FUUT-je may be a second one).

---

Q: After reading subsystem overview paragraph I am still not sure what are the subsystems of GMT :)! Is it only gcore and spectoolgenerator(See also previous question)? gcore seem like logical subsystems! But what are the others, Workflow?

A: gcore is the subsystem that provides the interface to all the MDA tool components. Workflow should reside withing gcore, because it is the "core" of GMT. Any other subsystems outside gcore should not have any dependencies to or from any MDA tool components. Examples for other subsystems: one for integrating with the eclipse ide platform, any gmt presentation/UI (how much of that we need depends on whether we need to define workflows withing gmt, or whether we can leverage some open source workflow tool that already has a UI), etc.

---

Q: Is there compact 3-5 sentance free text description for each subsystem? Now those description are spread through the document.

A: That is already the case in the UML model.

---

Q: I think in architecture document we should also describe decomposition of gcore itself in more details!

A: Only to a certain point - to clarify the responsibilities of gcore and to define the gcore interface (in the form of Java interfaces with complete signatures). Look at org.eclipse.emf.ecore to see how a good package hierarchy is constructed, i.e. the interfaces that represent the subsystem facade are defined immediately outside the package that implements the subsystem. The nitty-gritty internals of GMT workflow should go into a workflow design document. But we may not even need that much of that if we leverage an external workflow tool.

---

Q: concept of "ecorewrapper" I believe is a bit out of scope of GMT architecture. Why should GMT care how tool components will implement dependency? For example why should GMT bother how for example GME will implement the integration. We should not care on architecture level if they would do package called ecorewrapper or they will structure their classes any other way. Though, it doesn't mean we should care on political level and not try to help to do this integration. ecorewrapper package itself will not help plugging the component. I think of bigger interest would be specific interfaces and ways of plugging those components and that should be discussed in architecture document.

A: The package name is not so important, let's just call it <<ecorewrapper>> so that we've got a name to refer to it. The intention of this early version of the document is to draw a line in the sand regarding the dependencies that are permissible. The important message: no dependencies whatsoever from gcore on specific MDA tool components. And no dependencies from MDA tool components on any GMT package beyond gcore. The details of the gcore interface and the requirements on <<ecorewrapper>> packages will come as the next step.

---

Q: In Figure 1 you mix different levels of packages. I think it is not very good to have eclipse and ecore on the same level. It is not very clear what dependency is this and why is it important to be on the model!

A: the "eclipse" package there just stands for the relevant eclipse platform stuff that serves as the foundation. I have not looked at that yet, so don't take the package name literally.

---

Q: In Figure 1. What does the yellow box Generative Model Transformer means?

A: It's the top level package that contains gcore, and any other gmt subsystems.

---

Q: "This architecture keeps GMT focussed on tool component orchestration and on providing the integration with the org.eclipse IDE platform". HOW? It would be good to see more details.

A: Still to be done, but within the allowable dependencies defined in the architecture document.

---

Q: Figure 2. Doesn't explain much to me! What I read from this diagram is that all tool components depend on ecore and gcore. It didn't give promised idea of how MDA tool components will hook into GMT platform. What are the interfaces?

A: See above. Patience, we'll get to that. I've seen too many teams get excited about "internal design" and rush into the supposedly "cool" stuff completely forgetting the bigger picture and creating external dependencies on zillions of things.

---

Q: Figure 3. GMT package is a bit confusing. "examples" are "fuut" are they really ment to be there?

A: These things are part of the complete GMT package, but they are certainly not part of the GMT functionality that a user would typically use. "fuut" should become just another "MDA tool component" (or two if Ghica wants to keep the visual editor as well).

---

Q: Now we have Logical View only. Is there any specific reason or is it only time constraint? I would like to see for example mapping with Use Case Model and some kind of implementation view also.

A: Yes, time...Yes we need to relate the use case view to the logical view. The implementation and deployment view are usually not a big deal and can be added as appropriate.

---

Q: "For this purpose GMT will come equipped with a default set of code generation templates that delivers a web-based specification tool that is suitable for use in a distributed team environment.". Web-based tool doesn't seam for me as remedy for distributed team environment. I don't believe it is possible to develop this in near future.

A: I think you may not yet see what this is about. In a nutshell, in a distributed environment development teams of different subsystems are typically in different locations, however all the modeling artefacts need to be accessible to everyone just like normal source code. A web based application modeling environment greatly eases deployment in a large choatic environment, where developer desktops are not standardised etc. It's actually not such a big deal at all to get a simple version of that working.

---

Q: Workflow component description is not very well connected now. It would be good to have better description of how workflow fits into GMT.

A: To see what we need from a workflow component we should not theorise, but look at the concrete requirements of "wiring up" oAW to talk to GME via GMT or "wiring up" FUUTje/Velocity to talk to GME via GMT. To be attractive to users the workflow needs to happen as much as possibl behind the scenes, and the user should be working with a "GMT perspective" within Eclipse to launch tools as needed. Again, maybe we don't need a full-blown workflow engine but just the Eclipse plug-in architecture. We can qualify the requirements by mapping out concrete scenarios of the GMT use cases that explicitly refer to oAW, FUUT-je/Velocity, GME, etc. This will lead to concrete worflow requirements, and we use these as the starting point to define the gcore interface(s).

---

-- MarkKofman - 28 Jun 2004

GMT Core Discussions

1. WhatIsGmtCore^? (discussion of the role of GMT core component)
2. GmtArchitecture (GMT Architecture)
3. GmtRoadmap (Discussion of GMT Roadmap)

-- MarkKofman - 28 Jun 2004

GMT First Iteration

1. CvsStructure^? (Thoughts on strucure of GMT development artifacts)
2. GmtPackaging (Thoughts on GMT packaging and distribution)
3. EmfExpirience (EMF expirience report)

-- MarkKofman - 26 Sep 2004

Distributed version should have collection:

• Eclipse plugins
• Stand alone components
• Documentation
• Source and build script for source distribution

---

-- MarkKofman - 26 Sep 2004

This is intendet to be a collection of questions and answers regarding GMT roadmap. It also is meant to store old discussion and to make GMT more clear to newcomers.

Should not we move our roadmap document into the Wiki? It would be a better way to evolve roadmap. -- MarkKofman

ROADMAP

Q: To follow agile approach promised in MDSD so much I would like to see something executable GMT as soon as possible. How can we achieve this?

A: Think the roadmap does this (v0.1, v0.2, ...)

---

Q: General comment. You speak different "languages" in roadmap comparing to other parts of architecture document. You have talked about subsystems, ecore, gcore, MDA tool components. And in roadmap concepts like domain specific language, specification tool, EMF application,... jumps in without introduction. I would suggest to use terms from this architecture documents. Thats once again shows that we need proper Terminology for our project. It will avoid confusing ourselves and GMT users.

A: That will all be clarified by mapping the use case view onto the logical view, and by the GmtGlossary^?. But let's not create documentation for documentation sake, let's just create enough so that we are sure we're on the same page.

---

Q: version 0.1 goal. "In version 0.1 of GMT the specification tools that we use to capture models expressed in domain-specific languages can be EMF applications generated from meta models captured in Ecore." I am sorry, but I don't read our specific activities from this goal!

A: Yes this is the goal and not the set of activities to reach the goal. One of the next items to produce is a GMT project plan with activities that are assigned to individuals. A simple spreadsheet will do. Send in what you would like to contribute towards v0.1. I'll collect suggestions and coordinate the activities.

---

Q: version 0.1 goal. Why don't we validate ecore as foundation by trying to pluggin FUUTje?

A: As you have picked up, v0.1 is a very small step. Let's complete that first.

---

Q: I would have version 0.2 as 0.1 goal. I believe simplistic implementation of gcore is what we have to concentrate first, because it is the core component.

A: Patience. Unless we can satisfy ourselves that ecore and EMF works as we think it should, there's little point building gcore on an unproven foundation. (On steep house building sites for example engineers first test the ground for solidity and potential for slips etc before you start drawaing up plans for a building ;-) ecore is our building site... It can get very expensive if you're building on a difficult site ;-)

---

Q: I am getting the feeling that we are concentrating on creating MDA tool components instead of working on GMT core ideas. I hope this feeling is because I am still not very familiar with GMT. If not, then we should review roadmap goals.

A: The goals are driven by very down-to-earth, practical considerations. There will be more than enough "cool" work on gcore. The requirements for gcore need to be driven from concrete MDA tool component integration scenarios as outlined above. Otherwise we're building an ivory tower. See MDSD patterns on interaction between domain engineering and application engineering.

---

Q: If we say that we are using MDSD What step in is creating this architecture document is MDSD paradigm? What should be other activities done by now according to MDSD? Yes, I have read MDSD Activities paper ;) but what I am impling here is description of specific process of how we are going to use MDSD in GMT development. Sure only if we are going to do so!

A:

---

-- MarkKofman - 28 Jun 2004

First off lets make it easy on ourselves and NOT worry (yet) about distributed tool use (we can have this as an eventual goal, along with a "visual aspect). Web based or not I venture to say that whatever mechanisim we choose, once we introduce "distributed" use then the same problems will have to be addressed. --Jeff

Sure the distributed can come later, although once we have a web-based interface, the "only" ;-) other thing we need is a good central repository that can store models, see below. We could either use an SQL database or use an object database. What such a repository should allow you to do, is to open up a model for editing to a (small) group of people. --Jorn

:) I like your smile near "only". As soon as we have model repository there is no big difference how you access it. I think discussion on Web-based or not is not very much related to ModelAndTransformationManagement topic. What do you think? -- MarkKofman

Ultimately what I think you need is:

• a BA may sit together with a customer, capturing model information, while a designer is watching the model evolve in a different location, who may then modify bits and pieces.
• Similarly two designers/developers may collaboratively work on a shared model even though they're in different locations.
• Locking: As long as the models are accessible from multiple locations and updated in a repository as changes occur, it may be sufficient for one person to have a lock and others being able to watch the changes (live!). This works if the editing lock on a package (model part) can be passed around in a small virtual team like a token. (Like using a walkie tackie, you aquire the lock by pressing a button that signals your request to the current owner of the lock). The most important thing though is very simple: a locking mechanism at a "package" level, that gives access to a manageable model part to one person. Basically it amounts to shared workspaces for collaboration. If models get large, several separate workspaces can be used by different groups of people, with each workspace dealing with a separate package (model part). But to start, we can keep it very simple: One person locks a package and works on it and then check it back in. The "repository" can consist of XMI files and versioning is CVS (or "Subversion". Have you seen that yet? It's apparently "next generation" CVS). --Jorn
• Model comparisson and merge possibility -- MarkKofman
• Decomposition of the model -- MarkKofman

Web based or not its about generation of a specification tool for use with a specific meta-model. Having said that, a web based interface seems to work well with the idea of "Dynamic" (re)generation of a specification medium.

1. It works on almost all platforms and is (nearly) identical in appearence.
2. We have access to a good cross platform servlet reference implementation that is open-source (used by eGen, so we know it works).
3. We know it can work, even if we can't vouch for the distributed part. However, as I said earlier this is an issue that would have to be address regardless of the specification medium choosen.

--Jeff

Yes, exactly. --Jorn

Perhaps the alternatives would come with additional issues, who knows? --Jeff

1. OK, its good, but it doesn't help anyhow in solving needs described above.
2. I am not sure what do you mean here. Do you want to say that Tomcat is good enough?

I would also like to mention some negative points of Web-based tools. Those points in my opinion are quite important considering the fact that we are talking about development tools

• They are slow comparing to fat clients
• They are usualy inconvinient to use.
• They are harder to develop well
• There is a lot to reuse in Eclipse platform

To conclude I would say that still I don't see any big additional value comparing to Eclipse based solutions. If we are going to postpone model management problems, then we should also postpone solution ideas for now.

-- MarkKofman

Yes. That's why I suggest: let's see how far we get with EMF for version 0.1. Should hopefully allow us to bootstrap, and then focus on a single user, web-based interface for generated specification tools. --Jorn

-- JornBettin - 13 Jun 2004

1. ModelAndTransformationManagement
2. CodingConventions

-- JornBettin - 13 Jun 2004

Topic	Changed	By
WebStatistics	11 Feb 2008 - 01:12	TWikiGuest
WebContents	18 May 2005 - 10:50	AmudhaVijay
WebHome	02 Dec 2004 - 23:40	MartinBravenboer
EmfExpirience	26 Sep 2004 - 16:08	MarkKofman
GmtPackaging	26 Sep 2004 - 16:01	MarkKofman
GmtFirstIteration	26 Sep 2004 - 15:57	MarkKofman
FuutjeModeler	29 Jul 2004 - 21:54	GhicaVanEmdeBoas
FuutConfigurationImprovement	12 Jul 2004 - 19:31	GhicaVanEmdeBoas
WebNotify	07 Jul 2004 - 16:46	MarkKofman
FuutjeTemplateEngine	07 Jul 2004 - 06:58	MarkKofman
FuutConfiguration	06 Jul 2004 - 14:52	GhicaVanEmdeBoas
CodingConventions	05 Jul 2004 - 19:58	GhicaVanEmdeBoas
FuutRefactoring	03 Jul 2004 - 12:07	MarkKofman
TheBigPicture	03 Jul 2004 - 10:50	MarkKofman
FuutDependencies	28 Jun 2004 - 19:07	GhicaVanEmdeBoas
GmtRoadmap	28 Jun 2004 - 17:10	MarkKofman
GmtArchitecture	28 Jun 2004 - 16:49	MarkKofman
GmtCore	28 Jun 2004 - 16:35	MarkKofman
ModelAndTransformationManagement	28 Jun 2004 - 11:02	MarkKofman
WebChanges	02 Jun 2004 - 12:29	EelcoVisser
WebLeftBar	10 Feb 2004 - 21:59	EelcoVisser
WebRss	08 Feb 2004 - 22:11	MartinBravenboer
WebPreferences	01 Jul 2003 - 08:44	EelcoVisser
WebNews	21 May 2003 - 13:32	EelcoVisser
WebTools	18 May 2003 - 12:40	EelcoVisser
WebChanges100	06 Dec 2001 - 13:26	EelcoVisser
WebChanges200	06 Dec 2001 - 13:25	EelcoVisser
WebChanges500	06 Dec 2001 - 13:23	EelcoVisser
WebIndex	02 Dec 2001 - 21:20	EelcoVisser
WebSearch	09 May 2001 - 21:56	EelcoVisser

See also

• WebChanges100
• WebChanges200
• WebChanges500

Test Web

This is for testing

Generative Model Transformer

Edit WebContents to add links to the content bar on the left.

Edit WebPreferences to change color of the content bar.

---

This wiki is the Innovation Pipeline for the Generative Model Transformer project. Of course we also have the GMT mailing list and the GMT newsgroup. So how do all these channels fit together?

1. The GMT mailing list is the vehicle for communication regarding current development work and features that are on the GMT roadmap. I.e. the mailing list contains posts from those actively working on GMT.
2. The GMT newsgroup is the vehicle for GMT developers to communicate with the GMT user community and for GMT users ask questions about using GMT etc.
3. The GMT wiki, i.e. what you are looking at now, is the place where GMT users and GMT developers discuss and exchange ideas about future features of the GMT MDA/MDSD tool component platform that are not yet on the GMT roadmap.

Please use the structure below to navigate the GMT Innovation Pipeline, and add your suggestions as appropriate. The more concrete you can be in describing your requirements or your design ideas, the higher the chance that they will be picked up! Once sufficient material has been gathered, we will poll GMT users for their priorities.

---

GMT Tool Components

1. TheBigPicture (discussion of the big picture across GMT tool components)
2. GmtRoadmap (Discussion on GMT Roadmap)
3. GmtCore (the GMT component that orchestrates MDA/MDSD tool components)
4. GmtFirstIteration (GMT first iteration)
5. FuutjeTemplateEngine (the Fuut-je template engine)
6. FuutjeModeler (the Fuut-je visual modeling component)
7. FuutjeAndXML^? and Modeling (Discussion on the role of XML/XMI/XSD in modeling)
8. SpecificationToolGenerator^? (component to generate specification tools from meta models in Ecore format)
9. GmePlugin^? (enabling GME to plug into GmtCore)
10. OpenArchitecturEnginePlugin^? (enabling the Open Architectur Ware template engine to plug into GmtCore)
11. OpenArchitecturEditorPlugin^? (enabling the Open Architectur Ware template editor to plug into GmtCore)
12. FurtherToolComponents^? (suggestions for further MDA/MDSD tool components)
13. Information about the intended meta-model example used in GMT 0.1 at http://gmt.mdsd.info

• CodingConventions
• EmfExpirience
• FuutConfiguration
• FuutConfigurationImprovement
• FuutDependencies
• FuutRefactoring
• FuutjeModeler
• FuutjeTemplateEngine
• GmtArchitecture
• GmtCore
• GmtFirstIteration
• GmtPackaging
• GmtRoadmap
• ModelAndTransformationManagement
• TheBigPicture
• WebChanges
• WebChanges100
• WebChanges200
• WebChanges500
• WebContents
• WebCustomMenus
• WebHome
• WebIndex
• WebLeftBar
• WebNews
• WebNotify
• WebPreferences
• WebRss
• WebSearch
• WebStatistics
• WebTools

Number of topics: 31

WebHome
News
Changes

---

2004-06-02

Creation of the GMT web.

WebNotify is a subscription service to be automatically notified by email when topics change in the TWiki.Gmt web. This is a convenient service, so you do not have to come back and check all the time if something has changed. To subscribe to the service, please put yourself on the list below. The format is: 3 spaces * Main.yourWikiName - yourEmailAddress

• EelcoDolstra - eelco@cs.uu.nl
• EelcoVisser - visser+Transform@cs.uu.nl
• MartinBravenboer - martin@cs.uu.nl
• ArieVanDeursen - Arie.van.Deursen@cwi.nl
• MikeVanEmmerik - emmerik+Transform@itee.uq.edu.au
• ChrisRussell - cdr@encapsule.com
• AndrewMalton - ajmalton@uwaterloo.ca
• MarkKofman - kofman@kth.se

Related topics: TWikiUsers, TWikiRegistration

The following settings are web preferences of the TWiki.Gmt web. These preferences overwrite the site-level preferences in TWikiPreferences, and can be overwritten by user preferences (your personal topic, i.e. TWikiGuest in the TWiki.Main web)

Preferences:

• • Set PAGEHEADERCONTENTS = Program-Transformation.Org

• • Set WEBTITLE = Generative Model Transformer

• List of topics of the TWiki.Gmt web:
  • Set WEBTOPICLIST =

• Web specific background color: (Pick a lighter one of the StandardColors)
  • Set WEBBGCOLOR = #D0D0D0

• Web specific background color: (Pick a lighter one of the StandardColors)
  • Set WEBCONTENTBGCOLOR = #EEEEAA

• List this web in the SiteMap:
  • If yes, Set SITEMAPLIST = on, and add the "what" and "use to..." description for the site map. Make sure to list only links that include the name of the web, e.g. Gmt.Topic links.
  • Set SITEMAPLIST = on
  • Set SITEMAPWHAT = Generative Model Transformer
  • Set SITEMAPUSETO =

• Exclude web from a web="all" search: (Set to on for hidden webs)
  • Set NOSEARCHALL =

• Default template for new topics and form(s) for this web:
  • WebTopicEditTemplate^?: Default template for new topics in this web. (Site-level is used if topic does not exist)
  • TWiki.WebTopicEditTemplate: Site-level default template
  • TWikiForms: How to enable form(s)
  • Set WEBFORMS =

• Users or groups who are not / are allowed to view / change / rename topics in the Gmt web: (See TWikiAccessControl)
  • Set DENYWEBVIEW =
  • Set ALLOWWEBVIEW =
  • Set DENYWEBCHANGE = TWikiGuest
  • Set ALLOWWEBCHANGE =
  • Set DENYWEBRENAME = TWikiGuest
  • Set ALLOWWEBRENAME =

• Users or groups allowed to change or rename this WebPreferences topic: (I.e. TWikiAdminGroup)
  • Set ALLOWTOPICCHANGE = TWikiAdminGroup GmtAdminGroup
  • Set ALLOWTOPICRENAME = TWikiAdminGroup

• Web preferences that are not allowed to be overridden by user preferences:
  • Set FINALPREFERENCES = WEBTOPICLIST, DENYWEBVIEW, ALLOWWEBVIEW, DENYWEBCHANGE, ALLOWWEBCHANGE, DENYWEBRENAME, ALLOWWEBRENAME

Notes:

• A preference is defined as:
  6 spaces * Set NAME = value
  Example:
  • Set WEBBGCOLOR = #FFFFC0
• Preferences are used as TWikiVariables by enclosing the name in percent signs. Example:
  • When you write variable #D0D0D0 , it gets expanded to #D0D0D0 .
• The sequential order of the preference settings is significant. Define preferences that use other preferences first, i.e. set WEBCOPYRIGHT before WIKIWEBMASTER since =Copyright © 1999-2020 by the contributing authors.

All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback= uses the webmaster@strategoxt.org variable.

• You can introduce new preferences variables and use them in your topics and templates. There is no need to change the TWiki engine (Perl scripts).

Related Topics:

• TWikiPreferences has site-level preferences.
• TWikiUsers has a list of user topics. User topics can have optional user preferences.
• TWikiVariables has a list of common %VARIABLES%.
• TWikiAccessControl explains how to restrict access by users or groups.

/view/Gmt program-transformation.org en-us Copyright 2020 by contributing authors Eelco Visser [webmaster@strategoxt.org] Eelco Visser [webmaster@strategoxt.org] TWiki TWiki.Gmt /view/Gmt /pub/TWiki/TWikiLogos/twikiRobot46x50.gif /view/Gmt/WebStatistics?t=2008-02-11T01:12Z Statistics for TWiki.Gmt Web Month: Topic Views: Topic Saves: Attachment Uploads: Most Popular Topic Views: Top Contributors for Topic Save and Uploads: Feb 2008 ... (last changed by TWikiGuest) 2008-02-11T01:12Z guest 1.1586 updated major /rdiff/Gmt/WebStatistics /rdiff/Gmt/WebStatistics /view/Gmt/WebContents?t=2005-05-18T10:50Z Test Web This is for testing (last changed by AmudhaVijay) 2005-05-18T10:50Z AmudhaVijay 1.1 updated major /rdiff/Gmt/WebContents /rdiff/Gmt/WebContents /view/Gmt/WebHome?t=2004-12-02T23:40Z Generative Model Transformer Edit WebContents to add links to the content bar on the left. Edit WebPreferences to change color of the content bar. This wiki is the ... (last changed by MartinBravenboer) 2004-12-02T23:40Z MartinBravenboer 1.58 updated major /rdiff/Gmt/WebHome /rdiff/Gmt/WebHome /view/Gmt/EmfExpirience?t=2004-09-26T16:08Z 1 To be able store and load your resource as XMI you have to set-up Resource Type property to "XMI". By default resource type is not specified Main.MarkKofman 26 ... (last changed by MarkKofman) 2004-09-26T16:08Z MarkKofman 1.1 updated major /rdiff/Gmt/EmfExpirience /rdiff/Gmt/EmfExpirience /view/Gmt/GmtPackaging?t=2004-09-26T16:01Z Distributed version should have collection: Eclipse plugins Stand alone components Documentation Source and build script for source distribution Main.MarkKofman ... (last changed by MarkKofman) 2004-09-26T16:01Z MarkKofman 1.1 updated major /rdiff/Gmt/GmtPackaging /rdiff/Gmt/GmtPackaging /view/Gmt/GmtFirstIteration?t=2004-09-26T15:57Z GMT First Iteration 1 CvsStructure (Thoughts on strucure of GMT development artifacts) 1 GmtPackaging (Thoughts on GMT packaging and distribution) 1 EmfExpirience ... (last changed by MarkKofman) 2004-09-26T15:57Z MarkKofman 1.1 updated major /rdiff/Gmt/GmtFirstIteration /rdiff/Gmt/GmtFirstIteration /view/Gmt/FuutjeModeler?t=2004-07-29T21:54Z Models can be expressed in text, XMI etc. The most convenient form to visualize a model is trough a diagram. The most commonly used diagram notation is UML. A simple ... (last changed by GhicaVanEmdeBoas) 2004-07-29T21:54Z GhicaVanEmdeBoas 1.1 updated major /rdiff/Gmt/FuutjeModeler /rdiff/Gmt/FuutjeModeler /view/Gmt/FuutConfigurationImprovement?t=2004-07-12T19:31Z Before joining this discussion take a look at FuutConfiguration topic. Do You think, it is better to separate batch processing configuration and GUI application configuration ... (last changed by GhicaVanEmdeBoas) 2004-07-12T19:31Z GhicaVanEmdeBoas 1.3 updated major /rdiff/Gmt/FuutConfigurationImprovement /rdiff/Gmt/FuutConfigurationImprovement /view/Gmt/WebNotify?t=2004-07-07T16:46Z WebNotify is a subscription service to be automatically notified by email when topics change in the TWiki.Gmt web. This is a convenient service, so you do not have ... (last changed by MarkKofman) 2004-07-07T16:46Z MarkKofman 1.15 updated major /rdiff/Gmt/WebNotify /rdiff/Gmt/WebNotify /view/Gmt/FuutjeTemplateEngine?t=2004-07-07T06:58Z FUUTje Documentation 1 FuutBuild (Building FUUT tool) FUUTje Tool Open Discussions 1 FuutDependencies (discussion of FUUTje tool internal and external dependencies ... (last changed by MarkKofman) 2004-07-07T06:58Z MarkKofman 1.6 updated major /rdiff/Gmt/FuutjeTemplateEngine /rdiff/Gmt/FuutjeTemplateEngine /view/Gmt/FuutConfiguration?t=2004-07-06T14:52Z Since it is really difficult for a newbie to understand ideas behind the configuration of FUUT, i believe we need a document describing the purpose of each configuration ... (last changed by GhicaVanEmdeBoas) 2004-07-06T14:52Z GhicaVanEmdeBoas 1.2 updated major /rdiff/Gmt/FuutConfiguration /rdiff/Gmt/FuutConfiguration /view/Gmt/CodingConventions?t=2004-07-05T19:58Z Which conventions should we follow in GMT project? There are Eclipse conventions at http://dev.eclipse.org/conventions.html . Should we follow those blindly? In FUUT ... (last changed by GhicaVanEmdeBoas) 2004-07-05T19:58Z GhicaVanEmdeBoas 1.3 updated major /rdiff/Gmt/CodingConventions /rdiff/Gmt/CodingConventions /view/Gmt/FuutRefactoring?t=2004-07-03T12:07Z This is the list of refactoring ideas for FUUTje tool. Take any and implement it ;) Priority 1 Combine different plug-in loaders Priority 1 Improve FUUTje configuration ... (last changed by MarkKofman) 2004-07-03T12:07Z MarkKofman 1.1 updated major /rdiff/Gmt/FuutRefactoring /rdiff/Gmt/FuutRefactoring /view/Gmt/TheBigPicture?t=2004-07-03T10:50Z 1 ModelAndTransformationManagement 1 CodingConventions Main.JornBettin 13 Jun 2004 (last changed by MarkKofman) 2004-07-03T10:50Z MarkKofman 1.2 updated major /rdiff/Gmt/TheBigPicture /rdiff/Gmt/TheBigPicture /view/Gmt/FuutDependencies?t=2004-06-28T19:07Z I(Ghica) would like to make some remarks about splitting fuut into various jars, considering dependency management. Maybe we can talk about it tonight. A candidate ... (last changed by GhicaVanEmdeBoas) 2004-06-28T19:07Z GhicaVanEmdeBoas 1.2 updated major /rdiff/Gmt/FuutDependencies /rdiff/Gmt/FuutDependencies /view/Gmt/GmtRoadmap?t=2004-06-28T17:10Z This is intendet to be a collection of questions and answers regarding GMT roadmap. It also is meant to store old discussion and to make GMT more clear to newcomers ... (last changed by MarkKofman) 2004-06-28T17:10Z MarkKofman 1.1 updated major /rdiff/Gmt/GmtRoadmap /rdiff/Gmt/GmtRoadmap

• Simple search:

  Topic text (body)	All webs (not only TWiki.Gmt web)
  Topic name	BookView

• Advanced search:

  Topic text (body)	Search	all Main TWiki Know Test web(s)
  Topic name	Sort by	Topic name Last modified time Last editor in reversed order

  
  

  Make search:	Case sensitive	RegularExpression search
  Don't show:	search string	summaries   total matches
  Do show:	BookView	topics (result count)

• Topic index: List of TWiki.Gmt topics in alphabetical order.
  |All|A|B|C|D|E|F|G|H|I|J|K|L|M|N|O|P|Q|R|S|T|U|V|W|X|Y|Z|
  | All topics in BookView |

• Jump to topic: If you already know the name of the topic, enter the name of the topic at the second line of this page.

• WebChanges : Find out what topics in TWiki.Gmt have changed recently.

• How to edit text:
  • Make changes to topics in GoodStyle,
  • Learn the TextFormattingRules, and
  • Have a look at the TextFormattingFAQ.

Statistics for TWiki.Gmt Web

Month:	Topic Views:	Topic Saves:	Attachment Uploads:	Most Popular Topic Views:	Top Contributors for Topic Save and Uploads:
Feb 2008	1896	0	0	369 WebStatistics 224 WebHome 136 WebLeftBar 111 WebNotify  98 WebNews  93 WebChanges  83 WebRss  74 WebPreferences  47 WebChanges200  42 WebChanges500  41 WebTools
Jan 2008	5924	0	0	1378 WebStatistics 747 WebHome 355 WebChanges 282 WebRss 272 WebNotify 242 WebNews 214 WebLeftBar 172 WebPreferences 144 FuutjeTemplateEngine 115 FuutDependencies 108 WebTools
Dec 2007	3904	0	0	507 WebHome 441 WebStatistics 255 WebRss 218 WebChanges 205 WebNotify 182 WebNews 152 WebLeftBar 132 FuutjeTemplateEngine 108 TheBigPicture 107 WebSearch 107 WebPreferences
Nov 2007	2726	0	0	358 WebStatistics 325 WebHome 213 WebChanges 146 WebNews 145 WebNotify 127 WebLeftBar 122 WebRss 100 FuutjeTemplateEngine  98 WebPreferences  63 WebTools  62 WebSearch
Oct 2007	2929	0	0	561 WebStatistics 289 WebHome 170 WebNews 165 WebNotify 124 WebChanges 113 WebLeftBar 102 FuutjeTemplateEngine  85 WebPreferences  74 WebRss  73 TheBigPicture  72 FuutjeModeler
Sep 2007	3918	0	0	1059 WebStatistics 426 WebHome 192 WebNotify 185 WebChanges 177 WebNews 135 WebRss 102 WebPreferences  99 FuutjeTemplateEngine  90 WebSearch  88 TheBigPicture  78 WebIndex
Aug 2007	5360	0	0	1503 WebStatistics 567 WebHome 260 WebChanges 234 WebNotify 180 WebLeftBar 170 WebNews 134 WebPreferences 121 FuutjeTemplateEngine 119 WebChanges500 116 WebRss 111 TheBigPicture
Jul 2007	7513	0	0	1026 WebStatistics 1025 WebHome 400 WebChanges 397 WebNotify 339 WebNews 304 WebLeftBar 249 WebPreferences 222 FuutjeTemplateEngine 181 FuutDependencies 173 TheBigPicture 165 WebContents
Jun 2007	4086	0	0	438 WebHome 334 WebStatistics 220 WebLeftBar 196 WebChanges 189 WebNews 171 WebNotify 139 FuutjeTemplateEngine 132 WebPreferences 128 WebRss 117 TheBigPicture 114 WebContents
May 2007	3317	0	0	728 WebStatistics 299 WebHome 199 WebChanges 143 WebLeftBar 133 WebNotify 129 WebNews  88 WebRss  85 FuutjeTemplateEngine  81 TheBigPicture  77 WebPreferences  76 WebSearch
Apr 2007	3483	0	0	674 WebStatistics 354 WebHome 182 WebNotify 175 WebChanges 158 WebNews 117 WebIndex 113 WebLeftBar  96 FuutjeTemplateEngine  93 WebPreferences  92 WebSearch  89 TheBigPicture
Mar 2007	2876	0	0	354 WebHome 323 WebStatistics 149 WebNews 118 WebNotify 117 WebChanges 111 WebLeftBar 108 WebIndex 103 FuutjeTemplateEngine  95 WebRss  86 TheBigPicture  79 WebSearch
Feb 2007	3299	0	0	344 WebStatistics 255 WebHome 181 WebNews 180 WebChanges 132 WebNotify 124 WebLeftBar 117 WebIndex 113 WebPreferences 106 FuutjeTemplateEngine 104 WebRss  85 FuutConfigurationImprovement
Jan 2007	4322	0	0	1257 WebStatistics 427 WebHome 227 WebNews 175 WebLeftBar 152 WebChanges 145 WebNotify 119 WebIndex 104 FuutjeTemplateEngine  97 WebRss  92 WebPreferences  76 WebContents
Dec 2006	2539	0	0	296 WebHome 278 WebStatistics 124 WebChanges 110 WebNews 103 WebLeftBar  97 WebNotify  92 WebSearch  88 WebIndex  88 WebRss  81 GmtPackaging  73 FuutjeTemplateEngine
Nov 2006	2973	0	0	614 WebStatistics 245 WebHome 164 WebNews 127 WebChanges 118 WebLeftBar  94 WebRss  80 WebNotify  79 WebSearch  72 WebIndex  71 WebPreferences  70 CodingConventions
Oct 2006	3004	0	0	774 WebStatistics 285 WebHome 140 WebChanges 133 WebNews 125 WebLeftBar 115 WebIndex 109 WebNotify  74 FuutjeTemplateEngine  66 WebRss  66 WebPreferences  54 GmtCore
Sep 2006	3220	0	0	480 WebStatistics 234 WebHome 194 WebIndex 161 WebLeftBar 147 WebNews 141 WebNotify 121 WebChanges  97 WebRss  90 GmtCore  84 GmtRoadmap  81 TheBigPicture
Aug 2006	3758	0	0	556 WebStatistics 495 WebHome 208 WebIndex 177 WebChanges 162 WebNews 151 WebNotify 149 WebRss 117 WebLeftBar 113 FuutjeTemplateEngine 100 TheBigPicture  99 WebPreferences
Jul 2006	5209	0	0	997 WebStatistics 663 WebHome 305 WebNotify 259 WebNews 246 WebChanges 200 WebRss 198 WebLeftBar 179 WebIndex 144 WebPreferences 115 WebSearch 112 FuutjeTemplateEngine
Jun 2006	8323	0	0	2898 WebRss 1060 WebStatistics 848 WebHome 266 WebNews 234 WebNotify 234 WebChanges 234 WebLeftBar 164 WebPreferences 133 FuutjeTemplateEngine 130 WebIndex 120 WebSearch
May 2006	19622	0	0	11627 WebRss 2809 WebStatistics 766 WebHome 431 WebChanges 365 WebNotify 275 WebLeftBar 252 WebNews 205 WebPreferences 197 WebSearch 192 WebIndex 171 FuutjeTemplateEngine
Apr 2006	15858	0	0	10297 WebRss 1106 WebStatistics 603 WebHome 350 WebChanges 295 WebNews 265 WebNotify 233 WebLeftBar 227 WebIndex 200 WebPreferences 168 WebSearch 127 WebChanges200
Mar 2006	10970	0	0	6399 WebRss 638 WebStatistics 609 WebHome 270 WebChanges 261 WebNotify 186 WebNews 166 WebIndex 157 WebSearch 156 WebLeftBar 142 FuutjeTemplateEngine 114 FuutDependencies
Feb 2006	11115	0	0	7768 WebRss 538 WebHome 538 WebStatistics 189 WebNotify 170 WebChanges 148 WebNews 130 WebPreferences 111 WebLeftBar  94 FuutjeTemplateEngine  90 CodingConventions  81 WebIndex
Jan 2006	4697	0	0	1403 WebRss 498 WebHome 494 WebStatistics 200 WebChanges 194 WebNotify 167 WebNews 130 WebPreferences 108 WebLeftBar 102 FuutjeTemplateEngine  89 WebSearch  82 WebIndex
Dec 2005	17845	0	0	13957 WebRss 814 WebHome 578 WebStatistics 261 WebNotify 199 WebChanges 191 WebNews 163 WebLeftBar 116 WebPreferences 115 WebSearch 102 WebIndex 101 FuutjeTemplateEngine
Nov 2005	12350	0	0	7671 WebRss 1639 WebStatistics 663 WebHome 252 WebNotify 184 WebChanges 135 WebIndex 134 WebLeftBar 134 WebNews 107 WebSearch 107 WebPreferences 101 FuutjeTemplateEngine
Oct 2005	7950	0	0	4777 WebRss 580 WebHome 207 WebNotify 191 WebChanges 161 WebIndex 135 WebNews 132 WebLeftBar  98 WebSearch  98 TheBigPicture  96 FuutjeTemplateEngine  93 CodingConventions
Sep 2005	5414	0	0	3678 WebRss 281 WebHome 106 WebNotify  85 WebChanges  72 WebIndex  72 WebNews  62 WebSearch  58 TheBigPicture  58 WebStatistics  56 CodingConventions  55 FuutjeTemplateEngine
Aug 2005	5318	0	0	3601 WebRss 308 WebHome 134 WebChanges 111 WebNotify 102 WebIndex  71 WebLeftBar  57 TheBigPicture  57 WebNews  54 FuutjeTemplateEngine  54 WebSearch  50 WebStatistics
Jul 2005	8486	0	0	6384 WebRss 361 WebHome 132 WebChanges 124 WebIndex  97 WebNotify  90 WebNews  78 WebStatistics  66 WebPreferences  63 TheBigPicture  60 FuutConfiguration  59 FuutjeTemplateEngine
Jun 2005	9502	0	0	7951 WebRss 341 WebHome  82 WebChanges  80 WebNotify  77 WebNews  60 TheBigPicture  56 FuutjeTemplateEngine  50 WebIndex  50 WebStatistics  48 WebPreferences  45 ModelAndTransformationManagement
May 2005	6991	4	1	5449 WebRss 305 WebHome  93 WebChanges  70 WebNews  65 TheBigPicture  62 FuutjeTemplateEngine  55 WebNotify  51 GmtArchitecture  50 GmtCore  44 ModelAndTransformationManagement  44 WebStatistics	5 AmudhaVijay
Apr 2005	1801	0	0	375 WebHome 227 WebRss 108 WebChanges  87 WebNews  76 WebPreferences  76 TheBigPicture  62 ModelAndTransformationManagement  61 WebNotify  60 WebContents  44 FuutjeTemplateEngine  44 WebStatistics
Mar 2005	1947	0	0	400 WebRss 378 WebHome 214 WebChanges  98 TheBigPicture  61 WebPreferences  59 ModelAndTransformationManagement  57 WebNews  56 WebContents  48 FuutjeTemplateEngine  47 WebChanges100  41 GmtRoadmap
Feb 2005	1404	0	0	310 WebHome 249 WebRss  80 WebNews  79 WebChanges  57 WebPreferences  47 WebContents  45 TheBigPicture  41 WebNotify  35 ModelAndTransformationManagement  34 FuutjeTemplateEngine  27 WebSearch
Jan 2005	1697	0	0	384 WebHome 301 WebRss  96 TheBigPicture  88 WebNews  87 WebChanges  70 ModelAndTransformationManagement  59 GmtRoadmap  51 WebPreferences  46 GmtCore  45 WebContents  44 FuutjeTemplateEngine
Dec 2004	1292	6	0	336 WebHome 144 WebRss  69 WebChanges  66 TheBigPicture  61 WebNews  53 WebPreferences  42 FuutjeTemplateEngine  41 ModelAndTransformationManagement  36 WebNotify  33 WebSearch  33 FuutjeModeler	6 MartinBravenboer
Nov 2004	994	0	0	347 WebRss 141 WebHome  47 TheBigPicture  37 ModelAndTransformationManagement  32 WebChanges  29 GmtRoadmap  29 GmtArchitecture  26 GmtCore  25 GmtFirstIteration  25 FuutjeModeler  24 FuutjeTemplateEngine
Oct 2004	897	0	0	223 WebHome 184 WebRss  64 TheBigPicture  51 ModelAndTransformationManagement  40 GmtRoadmap  30 GmtCore  27 WebChanges  26 GmtArchitecture  26 CodingConventions  25 FuutjeTemplateEngine  25 FuutjeModeler
Sep 2004	1192	4	0	590 WebHome 206 WebRss  49 TheBigPicture  44 ModelAndTransformationManagement  31 GmtRoadmap  29 FuutjeModeler  22 WebNews  22 GmtCore  20 WebChanges  18 FuutjeTemplateEngine  17 GmtArchitecture	4 MarkKofman
Aug 2004	786	0	0	230 WebHome  72 TheBigPicture  66 ModelAndTransformationManagement  42 WebRss  38 GmtRoadmap  36 GmtCore  36 FuutjeTemplateEngine  34 CodingConventions  33 FuutjeModeler  28 GmtArchitecture  21 WebNews
Jul 2004	1166	28	0	335 WebHome 119 TheBigPicture  97 ModelAndTransformationManagement  85 WebChanges  78 FuutjeTemplateEngine  63 GmtRoadmap  54 GmtCore  53 CodingConventions  40 GmtArchitecture  32 FuutConfiguration  30 FuutDependencies	14 MarkKofman   9 GhicaVanEmdeBoas   5 AntonLitvinenko
Jun 2004	896	33	0	558 WebHome  48 WebChanges  42 ModelAndTransformationManagement  29 TheBigPicture  29 FuutDependencies  28 WebNews  17 WebPreferences  15 GmtRoadmap  14 WebContents  14 GmtCore  13 WebRss	17 MarkKofman   9 EelcoVisser   6 JornBettin   1 GhicaVanEmdeBoas
May 2004	64692	17	0	6234 DeCompilation? 3917 WebRss 1913 WebHome 1672 DecompilationResources? 1301 DecompilationCompilerSpecific? 1296 DecompilationDisassembly? 1231 DecompilationPossible? 1196 DecompilationGeneralApproach? 1157 JavaDecompilers? 1071 ProgramRefactoring? 921 DecompilationApplicationSpecificApproach?	5 MikeVanEmmerik   3 SimonMarsden   3 AndrewWalenstein   2 ManuelJimenez   2 ChrisRussell   1 MalcolmWallace   1 JeanHenrard
Apr 2004	80609	37	0	6282 DeCompilation? 3314 WebRss 2130 WebHome 2004 WebStatistics 1893 DecompilationDisassembly? 1798 DecompilationResources? 1733 DecompilationCompilerSpecific? 1470 DecompilationGeneralApproach? 1286 JavaDecompilers? 1206 DecompilationPossible? 1193 DecompilationApplicationSpecificApproach?	9 TomMens   8 MaratBoshernitsan   7 MikeVanEmmerik   7 MartinBravenboer   4 PierreEtienneMoreau   1 LaurentPloix?   1 EelcoVisser
Mar 2004	61381	46	0	6604 DeCompilation? 2284 WebRss 1938 WebHome 1721 DecompilationResources? 1584 DecompilationDisassembly? 1382 DecompilationCompilerSpecific? 1309 DecompilationGeneralApproach? 1201 DecompilationPossible? 1168 DecompilationApplicationSpecificApproach? 1052 JavaDecompilers? 937 ProgramTransformation?	17 MartinBravenboer   8 EelcoVisser   7 MikeVanEmmerik   5 TomMens   4 YijunYu   3 HenrikBach   1 SelimLevent   1 AndrewMalton
Feb 2004	44176	54	0	6193 DeCompilation? 1559 WebHome 1395 DecompilationResources? 1272 DecompilationPossible? 1239 JavaDecompilers? 1066 DecompilationGeneralApproach? 1052 DecompilationCompilerSpecific? 1003 DecompilationDisassembly? 809 AutomaticDecompiler? 784 DotNetDecompilers? 631 ReengineeringWiki?	35 MartinBravenboer  11 MikeVanEmmerik   7 EelcoVisser   1 ZhaoWay
Jan 2004	3578	34	0	462 WebHome  58 DeCompilation?  17 DecompilationResources?  17 DecompilationDisassembly?  15 DecompilationCompilerSpecific?  14 DecompilationPossible?  13 WebStatistics  13 JavaLanguage?  13 DecompilationGeneralApproach?  13 DecompilationApplicationSpecificApproach?  12 WebChanges	19 MikeVanEmmerik  13 MartinBravenboer   2 JeffGray
Dec 2003	9088	15	4	845 WebStatistics 346 WebHome  77 DecompilationApplicationSpecificApproach?  74 DeCompilation?  62 TransformationPeople?  51 TransformationConferences?  49 TransformationSystems?  49 ReengineeringWiki?  48 TransformationCompanies?  42 SoftwareEvolution?  38 DecompilationResources?	13 MikeVanEmmerik   4 EelcoVisser   1 LinHu   1 LarsVanJeurissen
Nov 2003	8602	16	0	75 WebHome  59 ReengineeringWikiSiteMap?  58 DomainEngineering?  38 VariabilityManagement?  36 DomainAnalysis?  33 SoftwareProductLine?  26 OrganizationDomainModeling?  26 FeatureOrientedDomainAnalysis?  26 FeatureModel?  23 FeatureDiagram?  22 DomainDesign?	10 MikeVanEmmerik   2 WillNorris   2 PinkuSurana   1 JensTroeger?   1 EelcoVisser
Oct 2003	8658	25	0	789 WebStatistics  78 DecompilationApplicationSpecificApproach?  67 DeCompilation?  64 WebHome  58 TransformationPeople?  56 TransformationConferences?  51 ReengineeringWiki?  49 TransformationSystems?  46 TransformationCompanies?  40 SoftwareEvolution?  38 DecompilationResources?	15 ReengineeringGuest   7 MikeVanEmmerik   2 MartinBravenboer   1 ZhaoWay
Sep 2003	1522	19	1	68 DeCompilation?  25 ReengineeringWikiSiteMap?  25 GenerativeTools?  23 ArieVanDeursen?  23 ArchitectureExtraction?  22 DomainEngineering?  18 GenerativeEvents?  16 WebStatistics  16 GenerativeProgrammingWiki?  15 VariabilityManagement?  15 DomainAnalysis?	12 MikeVanEmmerik   4 EelcoVisser   2 ArthurVanDam   1 RobVanOmmering   1 PatrickBrannan
Aug 2003	3494	24	0	21 WebStatistics  15 WebHome  14 DeCompilation?  11 CodeWorker?  11 CategoryPaper?   9 VariabilityManagement?   9 TransformationPeople?   9 TransformationConferences?   9 TransformationCompanies?   9 ReengineeringWiki?   9 ProgramTransformation?	11 MikeVanEmmerik   7 SergeDemeyer   5 CedricLemaire   1 ThomasGenssler
Jul 2003	6245	62	5	48 WebHome  33 ProgramTransformation?  27 WebStatistics  27 DeCompilation?  23 WorkshopOnRuleBasedProgramming?  22 ReengineeringWiki?  22 GenerativeProgrammingWiki?  20 DomainSpecificLanguages?  20 CategoryPaper?  19 WebChanges  19 TransformationCompanies?	57 MikeVanEmmerik   6 EelcoVisser   2 JornBettin   1 HolgerKienle   1 BrianWood?
Jun 2003	2532	58	2	34 WebHome  28 SoftwareEvolution?  17 WorkshopOnRuleBasedProgramming?  14 BENEVOL  13 DeCompilation?  12 WebChanges  12 TheEssenceOfStrategicProgramming?  12 DecompilationPossible?  11 WebStatistics  11 ProgramTransformation?  10 ASurveyOfRewritingStrategiesInProgramTransformationSystems?	24 TomMens  14 MikeVanEmmerik  14 KimMens   4 EelcoVisser   3 ArieVanDeursen   1 MaD
May 2003	2511	64	0	140 WebHome  50 DeCompilation?  29 SoftwareEvolution?  27 WebStatistics  25 ProgramRefactoring?  20 DecompilationDisassembly?  17 WorkshopOnRuleBasedProgramming?  16 WebNews  16 WebChanges  16 ReengineeringWiki?  16 GenerativeProgrammingWiki?	43 TomMens  15 EelcoVisser   5 MikeVanEmmerik   1 HolgerKienle
Apr 2003	1190	14	0	33 WebStatistics  12 DeCompilation?   7 WebHome   7 WebChanges   7 ReengineeringWiki?   7 ProgramTransformation?   5 WorkshopOnRuleBasedProgramming?   5 RigiSystem?   4 TransformationPeople?   4 TeachingSoftwareEvolution?   4 DomainSpecificLanguages?	9 JeanHenrard   2 MikeVanEmmerik   2 ArieVanDeursen   1 DerekRoss
Mar 2003	531	107	0	29 WebStatistics  20 DecompilationSalamanderTest?  11 WebChanges  11 DecompilationApplicationSpecificApproach?  10 DotNetDecompilerTests?  10 DeCompilation?   6 DecompilationAnakrinoTest?   5 DecompilerDesquirrTest?   4 MachineCodeDecompilerTests?   4 DotNetDecompilers?   4 DecompilerImageViewerDotNetSource?	97 MikeVanEmmerik   8 MartinBravenboer   2 ArieVanDeursen
Feb 2003	1017	268	5	74 DeCompilation?  44 TransformationCompanies?  29 DecompilationApplicationSpecificApproach?  26 WebStatistics  14 DecompilationJasciiTest?  14 CompaniesOfferingDecompilationServices?  13 WebHome  13 WebChanges  12 WebNews  12 DecompilationDava?  11 GenerativeCompanies?	231 MikeVanEmmerik  19 ArieVanDeursen   8 ReengineeringGuest   7 RudolfFerenc   4 MartinBravenboer   3 EelcoVisser   1 ChrisRussell
Jan 2003	409	184	2	63 ReengineeringWikiSiteMap?  45 TransformationCompanies?  30 WebStatistics  30 DecompilationDava?  22 DecompilationJrpTest?  21 DecompilationApplicationSpecificApproach?  14 DeCompilation?  13 DecompilationJodeTest?  13 CompaniesOfferingDecompilationServices?  12 WebHome  11 DecompilationGeneralApproach?	162 MikeVanEmmerik  11 RudolfFerenc   8 ArieVanDeursen   3 SwarmDagstuhl   2 EelcoVisser
Dec 2002	1978	21	0	580 ReengineeringWikiSiteMap?  61 WebHome  30 WebStatistics   8 WorkshopOnRuleBasedProgramming?   8 WebChanges   6 TransformationCompanies?   6 DocumentationGeneration?   5 ReverseEngineering?   5 MikeVanEmmerik?   4 WebTools   4 WebSearch	7 TomFowler   6 ArieVanDeursen   3 MikeVanEmmerik   2 JuhaPekkaTolvanen   2 EelcoVisser   1 RickScott
Nov 2002	1599	60	4	22 GenerativeCoreConcepts?  18 WebStatistics  16 WebHome  16 WebChanges  14 ReengineeringWikiSiteMap?   9 WorkshopOnRuleBasedProgramming?   7 WebNews   7 GenerativeTechniquesInTheContextOfModelDrivenArchitecture?   6 TransformationPeople?   6 LeonMoonen?   6 JeanMarieFavre?	25 KrzysztofCzarnecki   9 JeanMarieFavre   9 EelcoVisser   9 ArieVanDeursen   6 MikeVanEmmerik   4 JornBettin   1 GermanVidal   1 CorneliaBoldyreff
Oct 2002	3852	98	0	34 WebStatistics  31 WorkshopOnRuleBasedProgramming?  24 WebHome  22 WebChanges  15 ReengineeringWiki?  14 TransformationSystems?  13 ProgramTransformation?  13 DomainEngineering?  13 CategoryCategory?  12 CategoryEntryPoint?  11 TransformationConferences?	53 HolgerKienle  22 ArieVanDeursen   8 EelcoVisser   7 StephenHeffner   5 JornBettin   1 GermanVidal   1 EvavanEmden   1 CraigCleaveland
Sep 2002	8447	44	0	1043 DeCompilation? 596 WebHome 269 WorkshopOnRuleBasedProgramming? 149 ProgramTransformation? 145 ReengineeringWiki? 126 DecompilationPossible? 114 DecompilationResources? 113 GenerativeProgrammingWiki? 110 DecompilationCompilerSpecific? 106 DecompilationApplicationSpecificApproach? 100 DecompilationGeneralApproach?	25 ArieVanDeursen   5 MaD   4 MikeVanEmmerik   3 MartinBravenboer   3 EelcoVisser   2 MarkusVoelter   1 SebastianPop   1 DidierParigot
Aug 2002	17819	66	0	2039 DeCompilation? 1056 WebHome 417 WorkshopOnRuleBasedProgramming? 366 ProgramTransformation? 321 ReengineeringWiki? 257 DecompilationPossible? 256 GenerativeProgrammingWiki? 245 DecompilationDisassembly? 239 DecompilationResources? 226 DecompilationCompilerSpecific? 190 DecompilationGeneralApproach?	38 ArieVanDeursen  14 EelcoVisser   6 TWikiGuest   5 MikeVanEmmerik   2 MontyZukowski   1 MartinBravenboer
Jul 2002	18633	20	0	4499 DeCompilation? 1273 WebHome 594 DecompilationDisassembly? 536 ProgramTransformation? 519 DecompilationPossible? 480 DecompilationResources? 472 DecompilationGeneralApproach? 426 ReengineeringWiki? 332 DecompilationCompilerSpecific? 291 DecompilationApplicationSpecificApproach? 284 GenerativeProgrammingWiki?	7 MikeVanEmmerik   7 MaD   3 ThomasGenssler   1 TWikiGuest   1 HolgerKienle   1 ArieVanDeursen
Jun 2002	21200	53	0	5104 DeCompilation? 1801 WebHome 623 DecompilationPossible? 620 DecompilationResources? 560 DecompilationDisassembly? 519 ReengineeringWiki? 436 WorkshopOnRuleBasedProgramming? 395 DecompilationCompilerSpecific? 376 DecompilationApplicationSpecificApproach? 363 DecompilationGeneralApproach? 353 ProgramTransformation?	22 MikeVanEmmerik  20 EelcoVisser   7 ArieVanDeursen   2 MerijnDeJonge   2 DavidEriksson
May 2002	34808	89	0	5622 DeCompilation? 1300 WebHome 832 WebStatistics 679 DecompilationPossible? 659 DecompilationDisassembly? 652 DecompilationResources? 586 ReengineeringWiki? 508 DecompilationCompilerSpecific? 501 DecompilationApplicationSpecificApproach? 463 ProgramTransformation? 438 GenerativeProgrammingWiki?	14 MartinBravenboer  14 CraigCleaveland  11 MikeVanEmmerik  10 JornBettin  10 ArieVanDeursen   9 JoostVisser   9 IraBaxter   6 DavidEriksson   3 EelcoVisser   1 JeroenScheerder   1 BerndFischer
Apr 2002	23214	206	0	5528 DeCompilation? 1066 WebHome 698 DecompilationResources? 665 DecompilationDisassembly? 625 DecompilationPossible? 585 ReengineeringWiki? 481 DecompilationCompilerSpecific? 458 ProgramTransformation? 443 DecompilationApplicationSpecificApproach? 441 PcExeFormat? 421 DecompilationGeneralApproach?	109 JoostVisser  49 ArieVanDeursen  18 EelcoVisser  14 ElliotChikofsky  10 MikeVanEmmerik   3 TWikiGuest   2 GaneshSittampalam   1 DavidEriksson
Mar 2002	16127	258	2	5009 DeCompilation? 834 WebHome 605 DecompilationPossible? 602 DecompilationResources? 581 DecompilationDisassembly? 523 ReengineeringWiki? 468 DecompilationCompilerSpecific? 410 DecompilationApplicationSpecificApproach? 387 PcExeFormat? 386 ProgramTransformation? 335 DecompilationGeneralApproach?	116 ArieVanDeursen 112 TWikiGuest  28 EelcoVisser   2 MikeVanEmmerik   2 AndreyATerekhov
Feb 2002	23107	161	0	4730 DeCompilation? 1288 WebHome 552 DecompilationResources? 550 ReengineeringWiki? 537 DecompilationDisassembly? 536 ProgramTransformation? 490 DecompilationPossible? 396 PcExeFormat? 377 DecompilationCompilerSpecific? 345 DecompilationApplicationSpecificApproach? 336 DecompilationGeneralApproach?	104 ArieVanDeursen  21 MikeVanEmmerik  21 EelcoVisser   5 RudolfFerenc   4 JoostVisser   3 JurgenVinju   3 DavidEriksson
Jan 2002	22158	183	1	3102 DeCompilation? 1263 WebHome 427 ReengineeringWiki? 413 DecompilationDisassembly? 390 DecompilationResources? 374 ProgramTransformation? 334 DecompilationPossible? 317 DecompilationCompilerSpecific? 304 DecompilationApplicationSpecificApproach? 268 PcExeFormat? 222 DecompilationGeneralApproach?	105 ArieVanDeursen  56 EelcoVisser  21 MikeVanEmmerik   2 TWikiGuest
Dec 2001	21983	530	0	2861 DeCompilation? 1006 WebHome 445 DecompilationResources? 357 DecompilationDisassembly? 331 DecompilationPossible? 322 ProgramTransformation? 320 BinaryTranslation? 273 ReverseAndReengineeringRoadmap? 250 DecompilationCompilerSpecific? 246 PcExeFormat? 227 WebChanges	196 EelcoVisser 184 MikeVanEmmerik 122 ArieVanDeursen  14 JamesCordy   8 BerndFischer   2 JoostVisser   1 YanZhang   1 TWikiGuest   1 MartinBravenboer   1 GraemeChandler
Nov 2001	14309	427	3	1025 DeCompilation? 706 WebHome 274 ReengineeringWiki? 204 WebChanges 202 ProgramTransformation? 185 DecompilationDisassembly? 128 DecompilationPossible? 126 ReverseEngineering? 116 CategoryCategory? 104 DecompilationCompilerSpecific?  95 TransformationSystems?	216 MikeVanEmmerik 114 ArieVanDeursen  86 EelcoVisser   8 TWikiGuest   3 ChristopheDeDinechin   2 GraemeChandler   1 FransFaase
Oct 2001	28198	320	1	472 Transform 331 ReengineeringWiki 254 WebChanges 194 ProgramTransformation 170 ReverseEngineering 163 TheOnlineSurveyOfProgramTransformation 161 SwarmForum 138 TransformationSystems 133 ReengineeringWikiSiteMap 130 DomainEngineering	200 ArieVanDeursen 68 EelcoVisser 44 TWikiGuest 7 MartinBravenboer 1 FrankGerhardt? 1 BrianMitchell?
Sep 2001	25235	172	0	436 Transform 271 ReengineeringWiki 204 SwarmForum 174 WebChanges 156 ProgramTransformation 143 TheOnlineSurveyOfProgramTransformation 133 TransformationSystems 114 ProgrammingLanguages 107 DomainEngineering 100 ReverseEngineering	89 ArieVanDeursen 35 TWikiGuest 24 MaD 24 EelcoVisser
Aug 2001	21452	119	0	381 Transform 249 ReengineeringWiki 199 SwarmForum 150 WebChanges 128 ProgramTransformation 123 TheOnlineSurveyOfProgramTransformation 101 DomainEngineering 99 TransformationSystems 95 ReverseEngineering 92 TransformationPeople	76 ArieVanDeursen 25 TWikiGuest 12 EelcoVisser 4 GaneshSittampalam 2 MerijnDeJonge
Jul 2001	17804	36	0	259 Transform 130 ProgramTransformation 123 SwarmForum 98 ReengineeringWiki 83 TransformationSystems 83 TheOnlineSurveyOfProgramTransformation 71 DomainSpecificLanguages 67 DMS%20Toolkit 66 DomainEngineering 64 GenerativeProgrammingBook?	25 TWikiGuest 9 ArieVanDeursen 2 EelcoVisser
Jun 2001	15465	110	7	288 Transform 168 ReengineeringWiki 114 WebChanges 113 SwarmForum 112 ProgramTransformation 89 TransformationSystems 72 TheOnlineSurveyOfProgramTransformation 65 ProgrammingLanguages 65 DomainSpecificLanguages 62 TransformationCompanies	49 TWikiGuest 48 ArieVanDeursen 17 EelcoVisser 1 LeonMoonen? 1 HendrikBoom 1 ArneDeBruijn
May 2001	18463	253	0	424 Transform 213 ReengineeringWiki 170 ProgramTransformation 156 WebChanges 124 TheOnlineSurveyOfProgramTransformation 115 TransformationSystems 106 DomainSpecificLanguages 104 DomainEngineering 74 GenerativeProgrammingBook? 71 ProgrammingLanguages	115 ArieVanDeursen 71 EelcoVisser 66 TWikiGuest 1 RubenBoer?
Apr 2001	4435	89	0	223 Transform 173 ReengineeringWiki 105 WebChanges 76 TheOnlineSurveyOfProgramTransformation 59 ProgramTransformation 43 ProgrammingLanguages 42 DomainSpecificLanguages 41 TransformationSystems 31 TransformationPeople 30 SwarmForum	47 ArieVanDeursen 27 TWikiGuest 15 EelcoVisser
Mar 2001	7154	215	0	395 Transform 194 ReengineeringWiki 178 WebChanges 105 TheOnlineSurveyOfProgramTransformation 66 WebPreferences 59 WebLeftBar 55 ProgramTransformation 50 DomainSpecificLanguages 45 WikiWebs 45 WikiTools	82 TWikiGuest 72 EelcoVisser 53 ArieVanDeursen 8 JoostVisser

Notes:

• Do not edit this topic, it is updated automatically. (You can also force an update)
• TWikiDocumentation tells you how to enable the automatic updates of the statistics.
• Suggestion: You could archive this topic once a year and delete the previous year's statistics from the table.

Useful twiki things to do are:

• Keep track of WebChanges
• Get a WebNotify of changes
• Check the WebStatistics

• Browse the WebIndex
• Do a WebSearch

• See the other TWikiUsers
• Get your self a TWikiRegistration

• Set the WebPreferences
• Set the TWikiPreferences
• Set preferences for the left WebContents